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Abstract — With the advent of inexpensive simple humanoid robots, 
new classes of robotic questions can be considered experimentally. One 
of these is collective behavior of groups of humanoid robots, and in 
particular robot synchronization and swarming. The goal of this work is 
to robustly synchronize a group of humanoid robots, and to demonstrate 
the approach experimentally on a choreography of 8 robots. We aim to be 
robust to network latencies, and to allow robots to join or leave the group 
at any time (for example a fallen robot should be able to stand up to 
rejoin the choreography). Contraction theory is used to allow each robot 
in the group to synchronize to a common virtual oscillator, and quorum 
sensing strategies are exploited to fit within the available bandwidth. The 
humanoids used are Nao's, developed by Aldebaran Robotics. 

Index Terms — Nao, synchronization, contraction, quorum sensing. 

I. Introduction 

With the advent of inexpensive simple humanoid robots, new 
classes of robotic questions can be considered experimentally. One 
of these is collective behavior of groups of humanoid robots, and 
in particular robot synchronization and swarming. Among the great 
number of humanoid robot projects, one can think of the first robot 
to walk Asimo by Honda |1|, of the Humanoid Robotics Projet 
supported by AIST or Darwin created at Virginia Tech [3]. Toyota 
has also been working on his partner robots [4|. The Robocup (a 
competition of robot soccer) has also created a league for humanoid 
robots, and has adopted Nao, a french humanoid robot by Aldebaran 
Robotics 1 5 1, as it standard platform for the Standard Platform 
League. 

This work is the result of a collaboration between MIT's Nonlinear 
System Laboratory and Aldebaran Robotics, the French company 
who designed Nao. Nao is used worldwide in universities or in 
schools, mostly for research or education purposes. 

The aim of this work is to develop a program to synchronize 
the movements of a large group of robots, for example to realize 
a synchronized choreography. This project is different from most 
of the existing work on robot groups because it deals with strong 
synchronization rather than cooperation, like in Robocup. This kind 
of experiment has already been conducted by Aldebaran for the 
Universal Exposition in Shanghai in 2010 with 20 robots. Their 
approach was to synchronize every robot's clock by using the NTP 
protocol 1 6 1, which is currently use by every computer to synchronize 
its clock on Internet. Then all robots start the choreography at the 
same time, assuming every that every robot will have the same 
loading time. The drawback of this system is that it is not possible to 
compensate for an small error on one robot (if it starts with a delay 
for example), or to add a new robot during the choreography. So we 
tried to develop a more robust way to synchronize this behavior. 

Since our goal is really to ensure that every robot is acting precisely 
with the others (to do synchronization rather than collaboration), the 
issues that have to be solved are almost entirely network-related. If the 
robots had access to a perfect network (with immediate transmission 
of data between all the robots), a master-robot would have been able 
to sent immediate commands for every other robot, and they would 
have been synchronized. But with real networks, information takes 
time to propagate and this time can be highly variable. It can be as 
small as several milliseconds, but it can also take several seconds 
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in worst case, if the network has too much load for instance, and 
especially if using Wi-Fi. 

To synchronize clocks betweens two robots, we also use the NTP 
protocol. It allows every robot to share the same time, with an offset 
of a few milliseconds in worst case. But the robot will constantly 
adjust his speed to catch up with every other robot. 

To achieve this goal our work is based on two theoretical ideas : 
contraction theory (already used in another case of synchronization 
between humanoid robots |7|) and quorum sensing |8| . 

A video illustrating the result of this work is available on the Web, 
on the Aldebaran Robotics Youtube Channel. Q 

II. Contraction 

Contraction theory provides a framework to guarantee convergence 
of complex nonlinear systems, without using information concerning 
the limit trajectory (5). 

A. Contraction definition 

Let consider a system of the form : 

x = f(x,t) 

where a; is a size n vector. Let call Sx the virtual displacement. This 
virtual displacement is an infinitesimal displacement at fixed time. Its 
norm is then a measure of the difference between two trajectories. So 
the evolution of 8x{xq, t) is the evolution of the difference between 
the two trajectories with initial conditions at t = 0, a; = xq and 
x = xq + 8x(xo,t — 0). 

The evolution of Sx is given by : 

Sx = tJ-(x, t)8x 
ox 

It is then possible to calculate the evolution of the difference 
between two trajectories initially close : 

^-(8x T Sx) = 25x T 5x = 2Sx T ^f(x,t)Sx 
Let X m ax be the higher eigenvalue of the hermitian part of |j. 

4:(8x T Sx) < 2\ ma xSx T Sx 
dt 

By integration, we can upper bound 8x T 8x as 

||fc|| < \\6x \\Jo x """ {x ' t)dt 

If \max is negative on the whole trajectory, Sx will tend toward 
0, and this for every initial condition. If Xmax is negative in a stable 
region, every system starting in this region will tend toward a limit 
trajectory, independently of its initial condition. In this case we say 
that the system is contracting in this region. It will forget its initial 
condition exponentially fast. 

B, Generalization 

It's possible to generalize the previous proof by noticing that it 
does not depend on the definition of length. So we can use a more 
general definition of the length to prove the contraction definition, 
the exponential convergence will remain true in any other metric. 
The details of this generalization can be found in [9|. 

We can define this metric change by a matrix O, such as new 
coordinates are of the form 8z — OSx. Since this equation is not 
integrable in general, it's not always possible to define explicitly z 

'direct link : http://www.youtube.com/watch?v=WTeTI0H6M6s 
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in term of x. In the new coordinate system, the system is contracting 
if the largest eigenvalue of the symmetric part of 



F 



is negative 



C. Andronov-Hopf oscillator 

Consider the classical Andronov-Hopf oscillator, 1101 . 

x + (x 2 + y 2 - l)x + y = 
y + (x 2 + y 2 - l)y - x = 



(1) 



Its trajectories converge to the limit cycle x(t) = sin(t+8), y(t) = 
cos(t + 6) , as can be shown applying the invariant set theorem to 
the Lyapunov-LaSalle function E — x 2 + y 2 — 1 fTTI . 

This is an oscillator so obviously it is not contracting. The goal is to 
find a coupling between each oscillator to have all of them converge 
toward the same trajectory. Let consider a coupling between every 
oscillator, proportional to the difference of position in x and y. 



±i + (x 2 + y 2 

m + (x 2 + y 2 - 



l)xi + y 
l)2/i - x 



- Xi) 

Vi) 



The contraction of this system is shown in |10|. By adding NttXi 
in the first equation and Nnyi in the second, we can have the same 
right hand side term for every oscillator : 



x + (x 2 + y 2 + P)x + y = u(t) 
y+{x 2 +y 2 +/3)y-x = u(t) 



where /3 = kN 



1 and u(t) = k 



JV 



dx 



(x,t) 



3x 2 + y 2 + P 2yx + l 



2xy 



x 2 + 3y 2 + P 



The eigenvalues of the symmetric part of this matrix are P+x +y 
and P + 3x 2 + 3y 2 . So if P > the system is contracting, and the 
contraction rate is at least /3. So the distance between two trajectories 
will decrease at least like e _,3t [12), flOl . 

So it is at least P = Nn — 1, and close to the limit cycle (where 
x 2 + y 2 = 1), it's at least P — Nk. Here is a simulation of three 
oscillators, with k = 1 and initial conditions Xi(0) — — 1 + ^ 
and j/i(0) = 2 + jq. So the three oscillators starts in neighboring 
trajectories. And we have plotted on each of the following figure the 
evolution of a distance between oscillator 1 and 3, and the curves 
e -(jVre-i)t an( j e -(Ar K )t |Y| s j lows me difference in x, Fig. [2] 

shows the distance on the phase diagram, and Fig. [3] shows the 
difference in <t>. 
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Fig. 1. Evolution of \x\ — x%\ and of the contraction rate 




Fig. 2. Evolution of yj (xi — X3) 2 + (yi — J/3) 2 and of the contraction 




Fig. 3. Evolution of \<f>i — 4>i\ and of the contraction rate. The brown curve 
is overlaying the blue one. 



So every oscillator, independently of its initial conditions, will 
rejoin the other oscillators and oscillate with them. The difference 
between two oscillators will decrease with a exponentially speed 
proportional to /3. The limit cycle of the oscillators will be of the 
form x(t) = sin(t + 6),y(t) — cos(t + 9). 

III. Quorum sensing 

To have the best synchronization possible, it is necessary to have a 
fully-connected network - that is to say, every robot must have access 
to every other robot position, because if the distance between two 
robots increases, the time taken to detect and correct this difference 
will also increase. 

But on the other hand, the more links we have in the same network 
the more stress the network will have. So adding links will decrease 
the overall quality of every link and will also decrease the number of 
robots that will be able to synchronize in the same time on a given 
network. To simulate a fully-connected network while limiting the 
number of links, we can find inspiration in natural mechanisms, such 
as quorum sensing. The idea is to communicate through a global 
variable that everyone can access and modify, rather than with every 
other robot (8) 1131 . This strategy also reduces considerably the 
number of necessary connections. In biology 1 14], agents (bacteria) 
can emit a fixed quantity of chemical (so-called auto-inducer), and 
also measure the concentration of the chemical in its environment so 
as to have an estimate of the number of agents present locally. As the 
bacteria multiply, an infection is launched only once the concentration 
reaches a certain threshold, i.e., once there are enough other agents 
present and thus a "quorum" is reached. 

This phenomenon is reproduced here to calculate the mean of every 
oscillator position. It is then possible to couple oscillators directly 
with the mean, and the result will be the same in theory. 



3 



+ 0»i + Vi - l)a?i + 2/i = « Z)j=o( 



^■7 ) 



Nk 



'EL' 



y 4 + (a;? + y 2 - - x t = k £),•=,, (fj - 2/0 = 



To implement this system, it is compulsory to add at least one new 
node in the network to collect information of position for every node 
and to send back the mean. So in this case, we will have a star-shaped 
network (with a number of link proportional to N) to have the same 
synchronization speed of a fully-connected network (with a number 
of link proportional to iV 2 ). See Fig [4] 




Fig. 4. Comparaison of the network topology without (left) or with (right) 
quorum sensing 



Even if in this simple case there is only one central server to 
which every robot is connected, this is not a master/slave system. 
If the server (or the network) has trouble, the only thing the robots 
will miss will be their synchronization information. The oscillations 
will continue at the nominal speed, and the synchronization will not 
occur until the issue is solved. But if they are already synchronized, 
they will stay synchronized. 

It is also possible to easily distribute this system, so as to reduce 
the load of the server. If several servers are running in the same time, 
it is only needed that one robot sends its data to several servers to 
have all the robots on those servers synchronize. In this way, it is 
possible to have a distributed system if the workload is too large for 
a single server. 

To go further, it is also possible to put this server on every robot, 
and to use only the first one who join the choreography. If the first 
robot leaves, the robots have to elect one of their own to run the 
new server 1 15 1. If the first robot detects a workload too high, it can 
ask another robot to start its server, which will handle any incoming 
robot. 

Nevertheless, this system has a drawback : it takes two messages 
sent on the network to transmit an update from one robot to another. 
So the effect of any delay on the network will be amplified. To 
compensate for this, every data sent is sent with its time of emission 
and its derivative, to be able to predict its new value when needed. 
This is also used to drop a data that is too old. Alternatively, the 
same information may be conveyed by a single composite variable 
combining each data and its derivative II II . 

IV. Implementation 

In this paper we will focus on moving according to a predefined 
trajectory, like a choreography. 

A. Trajectory description 

We have seen in the two previous sections how to synchronize 
efficiently oscillators over a network, but we want to synchronize 
more complex trajectories. Since it is not possible to describe a 
complex trajectory as the limit cycle of a differential equation, 



we have to link directly the position of the oscillator to a robot 
position. We also want the movements to be close enough to nominal 
movement : the robots can go faster or slower to rejoin the others, but 
the movement has to be only slightly modified. Once synchronized, 
the robot has to move according to the nominal movement. 

To describe the movement of a robot inside a predefined choreog- 
raphy, one needs only to know its time position inside that choreog- 
raphy. So we only need to convert the position of our oscillator into 
a parameter going from to 1 uniformly and continuously to cover 
precisely the initial movement. 




Fig. 5. Phase diagram of an Andronov-Hopf oscillator {TJ with initial 
condition x(0) = y(0) = 1. 



By looking at the phase diagram (Fig. [5} for an Andronov-Hopf 
oscillator, we can see that the limit cycle is a perfect circle (and we 
have proved in section [IFC]l. By phase diagram we mean here a plot 
of x in respect of y. Indeed when E goes to zero, we have 

x + y — 
y — x — 

that is equivalent to y + y — 0. The phase diagram in this case 
would have been y in respect of y. We just replace y by x even if 
E is not null for the analogy. 

So by considering the angle in this phase portrait, we have a 
parameter that evolve between and 2ir periodically, and a small 
variation in the phase diagram (so in the oscillator state) will modify 
only slightly this angle. The evolution of this angle (called <j>) is 
plotted Fig |3] 

B. Oscillator speed ajustment 

To correctly reproduce a trajectory, it is necessary to adapt to its 
length, so to adapt the speed of the oscillator. Let {x(t),y(t)} be a 
solution of {T}, and then we will look for a differential equation 
satisfied by {x(ujt), y(tot)}. We have 4r(y(u)t)) = uiy(ujt) and 
&(x(ut)) = ux(ut). 



ujx(ujt) + (x(ujt) 2 + y(ujt) 2 
uy{u)t) + (x(u)t) 2 + y(cot) 2 



Vjx(ui) + y(ut) 
l)y(wt) — x{ujt) 



So {x(u}t), y(uit)} satisfy the differential equation 



x + uj[{x 2 + y 2 
y + uj[(x 2 +y 2 



l)x + y] 

l)y - x] 
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Fig. 6. 
radians. 



evolution of the Andronov-Hopf oscillator shown in Fig [5] in 



By modifying to in this equation, we will modify the speed of 
the oscillator without modifying the trajectory. The phase diagram 
will stay the same, it will just be covered in a different time. To be 
precise, the limit cycle will be covered with a period of — . 

To keep the same influence of synchronization, it is also compul- 
sory to replace k by lok in previous equation. So the final equation 
for the oscillator number i is : 



±i + cj[(xi + yf - l)xi + yi] = Nojk 
iji + tj[(xi + yf - l)yi - Xi] = Nun 



N(52j=o x i) Xi 



C. Music 

Another issue that has to be considered is the music. We aim at 
having something to do choreographies, so we need to be able to play 
music during the performance, and to synchronize the robots with the 
music. But it is not a good idea to change the speed of the music in 
real time : in human shows, the music stays at the same pace and 
only the dancers have to change their pace to synchronize. So we 
want the music to act as a leader : to share its oscillator position to 
allow the others to synchronize to itself but not to take into account 
the other robot positions. 

To prove that this behavior will act as we want, we have to use 
partial contraction 1161 . The idea is to build a virtual system from 
the real system, and to prove the contraction of this virtual system 
to get information on the real system. By proving the contraction of 
the whole system, we prove that every trajectory will converge to 
the other. Since the leader trajectory is a particular solution, every 
trajectory will tend toward this trajectory. Formally, if 

x = g{x,x,t) 
is a system, one can build the virtual system 

y = g(y,x,t) 

and proving the contraction of this new system will demonstrate 
that every solution will tend toward x (because i is a particular 
solution). This theory is developed more in depth in 1 16 1. Let X be 
[x,y] T . The system with a leader is : 



Nl ea der /(deader) 

Xi = f{Xi) + k (nx % - 



Xleader — f(Xl ea der^) 

N 

Xi = f(Xi) + k(n + lyXj-K^Xj - KXi eader ,ioT i = i..jv 



— g(Xj ) ,contractant 



j=i 



=«(*) 

Here we can recognize in g(Xi) the same system than before 
: the system which we have already proved the contraction. And 
u(t) is the same for any robot, so will not have any effects on the 
synchronization. Thus we have proved the partial contraction of the 
new system with the leader. 

We have then proved that with one robot who share its position 
without taking into account others' position, the synchronization 
remains. So this robot can be the musician, and if he start the music 
with its oscillator, the two will not change their respective speed so 
they will stay synchronized. This idea can also be used if we want to 
predict with a good accuracy the time when every robot will finish : 
they will all finish with the leader, which has a fixed speed. 

D. Robot implementation 

To achieve our initial goal, our implementation has to separate the 
calculation of the oscillator and the network communication because 
we don't want any perturbation from the network (latencies, lost 
message, etc ...) causing a shacking movement on the robot. So 
we separate the implementation in two different threads : one for 
the oscillator simulation and joint command and the other one for 
network communication. A schematic view is shown Fig. [7] 



Oscillator thread 



Network thread 



Numerical data 
update 



New state calculation 



Commands 
sending 




Data sent to 
tne server 



Data received 



Data received tfom 
tne server 



Fig. 7. Schematic robot implementation of this behavior 
To describe more in detail each task : 

• Oscillator initialization : For this initialization the robot has to 
determine its initial condition. For this he retrieve data from the 
server concerning the mean position of the group and estimate 
the position of group in 1 second. He then has 1 second to join 
this position, so when he will start to synchronize he will be 
close enough to the others. At the end of this step, the network 
thread can start since there is a virtual oscillator position to be 
shared with the others. 



+ K(Xi — Xleader),i = 1...N 



Numerical data update : To keep the oscillator calculation real- 
time, we use a calculation step (used in the numerical resolution 
of the oscillator differential equation) variable, and equal to 
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the time difference between the beginning of the last loop and 
the beginning of the current loop. During this tack, the robot 
calculate this step and use the current time to estimate the current 
mean of every other robot position (or to discard this information 
if it's too old, see next section for more information). 

• New state calculation : Here the robot can use a Euler method 
with the current state and the synchronization information es- 
timated on the previous task to calculate the next state of its 
virtual oscillator. These data are stored in a global variable to 
be accessed by the network thread. 

• Commands sending : With the new state available, a new cf> can 
be computed and a new robot position too. This new command 
is then sent to the robot to be reached in 150 ms (in addition 
to every remaining command). The movement will then be 
smooth (without interruption) if the calculation step remains 
under 150ms. 

• Network thread initialization : The robot connects itself to the 
server and request an update of the synchronization information. 

• Data sent to server : Sending syntonization data to the server, 
according to the new section 

• Data received from server : Receiving syntonization data to the 
server, according to the new section 

E. Server implementation 

The precise goal of this program is to receive the virtual oscillator 
position from every robot, and to send back to each of them the mean. 
The server can also receive configuration messages (like changing the 
coupling strength that is send back to every robot, stopping the server, 
...). Synchronization data are transmitted with the form : 



Message for the server 


timei : x : x : y : y; 


Answer from the serveur 


time2 : m x : m x : m y : m y : N : k; 



where timei is not the sending time, but the time of the calculation 
that leads to x and y. The values of x and y are send only to do 
prediction on x and y and are not directly used in the synchronization 
process. Every value is separated by a and every message finishes 
with a This way, it is easy to parse the incoming messages and 
separate them. 

Every robot expects a message of the form presented above, where 
m x is the mean of x and m y is the mean of y. Their derivatives are 
there for prediction, N is the total number of robot and k is the 
coupling strength. The server will send a copy of this message to 
every robot that are connected. Here again, time-2 is the time used to 
evaluate the mean, not the time of the sending. To be more precise 
m x is the mean of x% + (time-2 — timei (i)) * ii and rh x is the mean 
of ii (i is there the robot index). The fact that the server sends k 
allows the user to change the coupling in real time, so as to activate, 
increase or decrease its strength. 

V. Perspective of improvements 

In this implementation, the movements of the robots are not really 
related to the virtual oscillator movements. But for movement like 
walking, it is possible to do a stronger link and to deal for example 
with every initial condition (7). 

To go further, it could be useful to use the same quorum server 
to synchronize different types of oscillators. For example if several 
robots are running different choreography (with different length) or 
are walking with different pace (because of size differences between 
robots for example), each robot will have to decompose the quorum 



signal to find the part of the mean concerning the robot identical to 
itself. For example if 3 robots walking with 1 step/second and 3 robots 
with 0.5 step/second, each robot can filter the quorum signal for its 
corresponding frequency. With a fixed calculation step, it is possible 
to design filter with an arbitrary precision 1 17 1. With a non-constant 
step, one has to incorporate the step into the filter coefficients. But 
without knowing the total number of robots (but with the knowledge 
of the number of similar robot), a robot can synchronize with all the 
robots sharing the same speed. 

Another improvement could be to track the tempo of the music 
1181 , and see it as an oscillator. At the beginning the robot has to 
determine the frequency to configure its own oscillator, but will then 
be able to use the music instead of the quorum signal to synchronize. 
So every robot will synchronize its virtual oscillator to the music, so 
the movements performed will be synchronized with the music. It can 
also be a good way for the robot to improvise a dance on a music. 
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